collection

2.4. TC CALDAV

Work over last 4 months:

Shelved calendar resource drafts until/unless we see more client interest. We will refactor Managed Attachments to use Server Info Document once it stabilizes. Focused primarily on Server Info Document which now has an initial draft: draft-douglass-server-info.

  • Decisions:

    • Initial spec will probably punt on including per-service DAV properties/values

    • Define a Server-Info-Token response header that servers can use to notify clients of a change to server capabilities (rather than relying on clients to poll)

    • Need a way for clients to specifically request that the server return Server-Info-Token response header — currently If-Not-Server-Info-Token request header

  • Open Issues:

    • Should we use Server-Info-Token as both a request and response header or use a If-Not-Server-Info-Token request header as in current draft? Should we include “features” that are currently only discoverable via DAV properties, e.g. sync-collection, add-member, current-user-principal

    • Should we include a Link header with server-info-href and newly defined reltype in OPTIONS responses? Some investigation into a small number of clients yields that clients typically do a PROPFIND on .well-known before ever doing an OPTIONS, so a client could fetch server-info-href property in initial PROPFIND and potentially bypass OPTIONS completely

    • Should server-info-href be available on ALL resources or limited to just a sub-set of resources (e.g. .well-known, calendar-homeset, user principals)

Work for next 4 months:

Finish up the serverinfo document. Work on a public version of the CalDAV server matrix. Plan on a client version of the matrix.